MEV-Boost es un protocolo de extracción de MEV en Ethereum que depende en gran medida de un participante centralizado llamado Repetidor. Hemos propuesto una arquitectura alternativa que permite la comunicación directa y criptográficamente privada entre constructores y proponentes. Esta arquitectura se basa en una forma novedosa de encriptación de umbral 'silenciosa' no interactiva, que puede utilizar las llaves secretas BLS existentes de los validadores.

En esencia, proponemos utilizar el encriptación Bloquear de umbral para enviarlo a una parte de los participantes, de modo que el comité de pruebas de conocimiento pueda lograr la privacidad y la disponibilidad de datos. Sus pruebas forman la Llave secreta de descifrado; una vez que se alcanza el umbral requerido, el Bloquear puede ser descifrado.

Nuestra solución de construcción aborda el problema de privacidad entre los constructores y los proponentes, pero por sí sola no garantiza la efectividad del bloque. Puede combinarse con otros mecanismos para replicar completamente las funciones proporcionadas por el repetidor, incluyendo privacidad y efectividad del bloque. Por ejemplo, se pueden utilizar pruebas de entorno de ejecución confiable (TEE) o pruebas de conocimiento cero (ZK), o garantías de encriptación económica para los constructores.

Al eliminar la necesidad de los constructores de Repetidor para proporcionar privacidad y garantizar la efectividad del Bloquear, nuestro objetivo es reducir la latencia y aumentar la Descentralización y la capacidad de resistencia a la censura de Ethereum.

El papel de MEV-Boost y Repetidor

MEV-Boost es un protocolo intermediario de lado que actúa como intermediario entre constructores de Bloquear y proponentes. El papel principal del Repetidor es proporcionar dos garantías, como se describe [aquí] (https://ethresear.ch/t/relays-in-a-post-epbs-world/16278#h-2-relay-roles-today-3):

• Privacidad del constructor: El Repetidor garantiza que el proponente no pueda ver el contenido del Bloquear y no pueda robar el MEV encontrado por el constructor.
• Seguridad del proponente: El Repetidor garantiza que el constructor pague al proponente el valor comprometido según su oferta, y asegura que el Bloquear sea válido (por ejemplo, todos los pagos de transacciones cubran el costo interno del gas).

Sin embargo, la dependencia de Repetidor ha introducido una notable centralización. Aproximadamente el 90% de los bloques de la cadena de ETH se transmiten a través de solo unas pocas Repetidor. Esto conlleva varios riesgos:

• Descentralización: Los constructores pueden mejorar la eficiencia de latencia mediante la implementación conjunta con Repetidor en lugar de reflejar la distribución geográfica de los proponentes. Esto debilita directamente la Descentralización geográfica y la capacidad de resistir la censura que podríamos haber obtenido de una amplia distribución global de validadores.
• Ingresos: El procesamiento medio de bloques de extremo a extremo de un repetidor eficiente es de unos 5-20 milisegundos. Luego, también hay comunicación entre el constructor y el proponente. Omitir Repetidor reducirá la latencia, el riesgo de ejecución entre dominios de Soltar (por ejemplo, CEX/DEX) y, en última instancia, aumentará la recompensa MEV del proponente.

TEE-Boost

Una de las propuestas principales como alternativa a Repetidor es "TEE-Boost", que depende de un entorno de ejecución confiable (TEEs). Es importante tener en cuenta que TEEs no son el núcleo de nuestra solución; utilizar TEE-Boost como ejemplo educativo para el problema que estamos tratando de resolver es muy útil.

En concreto, TEE-Boost requiere que los constructores utilicen TEEs para crear pruebas de la honestidad de sus ofertas y la validez del bloquear, sin revelar el contenido real del bloquear al proponente. El proponente puede verificar estas pruebas en hardware común sin necesidad de ejecutar los TEEs ellos mismos.

Sin embargo, TEE-Boost tiene un problema de disponibilidad de datos: los constructores solo comparten pruebas de TEE y Bloquear cabecera con el proponente, pero no comparten el contenido real de Bloquear[1] y puede optar por no liberar el contenido del Bloquear después de que el proponente firme el encabezado (por ejemplo, si las condiciones del mercado cambian desfavorablemente). Los métodos propuestos para abordar este problema de disponibilidad de datos incluyen:

TEE-Guardian: TEE-Guardian obtiene el Bloquear de los constructores antes de que el proponente lo firme y lo libera después de ver la cabecera de firma.

Capa de disponibilidad de datos: Los constructores publicarán la carga de encriptación Bloquear en la capa de disponibilidad de datos (DA).

Ambos métodos tienen sus desventajas. La solución de custodia TEE replica la latencia dinámica centralizada similar a la Repetidor existente [2]。Si se utiliza una capa DA externa, se introducirán suposiciones de protocolo adicionales y se asumirá la latencia dinámica de este protocolo externo (que también puede ser desfavorable).

1. En teoría, si los proponentes también pueden acceder a los TEEs, los constructores pueden encriptarlos en el Bloquear ejecutado por el TEE del proponente. El TEE del proponente solo descifrará el Bloquear después de firmarlo. Sin embargo, creemos que TEE-Boost no ha considerado este diseño, ya que requeriría que los proponentes (validadores) ejecuten TEEs. Esperamos que los validadores puedan funcionar en hardware normal. ↩

2. Si el proponente ejecuta el TEE-Safekeeping como un proceso lateral desplegado junto con sus validadores Nodo, puede evitar la latencia dinámica

态。然而，我们同样不希望使validadores运行TEEs。↩

La criptografía de umbral se utiliza para preservar la privacidad del constructor

Hemos propuesto una solución elegante para abordar el problema de disponibilidad de datos de TEE-Boost: encriptación de umbral para el comité de validación. Específicamente, el constructor encripta el bloque con encriptación de umbral en una proporción especificada del comité de validación para ese intervalo de tiempo. Una vez recopiladas suficientes pruebas, el bloque se puede descifrar y utilizar.

El núcleo de la tecnología habilitadora es una encriptación de compuerta silenciosa. Esta técnica de criptografía [permite la encriptación cerrada] (https://eprint.iacr.org/2024/263) sin la necesidad de la fase de configuración de generación de secreta distribuida interactiva (DKG) requerida para la compilación anterior. Por el contrario, la Llave pública conjunta se calcula en base a la Llave pública BLS ya existente de validadores y algunos "indicios" (que se discutirán más adelante) de certeza.

Esto permite la comunicación directa de salto único entre constructores y validadores, con privacidad criptográfica. Los validadores no necesitan ejecutar TEEs o administrar ningún nuevo material de Llave secreta.

Mecanismo:

El constructor construye un Bloquear y lo encripta en el comité de validación.

El constructor construye una prueba de TEE y demuestra al comité de validación tres aspectos: la oferta es honesta, el Bloquear es válido y la encriptación es correcta.

El constructor transmite la prueba de límite de encriptación de Bloquear y TEE (incluido el valor de oferta) al proponente. SUP XY 01928374656574839201.[3]

El proponente firma la encriptación Bloquear del constructor ganador y difunde la propuesta al conjunto de validadores.

Una vez que el comité de validación designado en una proporción específica (por ejemplo, n/2 o 2n/3) autentica Bloquear, se descifra.

El Bloquear descifrado se confirmará normalmente al final.

3. Se debe realizar una investigación sobre el impacto de los requisitos de ancho de banda del proponente. Los proponentes de bajo ancho de banda pueden limitar sus requisitos mediante la validación de prueba antes de enviar al bloque principal, o mediante el uso de otras técnicas de filtrado heurístico y descarga inteligente. Este es un problema abierto, pero parece no ser más difícil de resolver que el problema regular de propagación de correo no deseado en el mempool. ↩

Precauciones

Rendimiento

Las características de rendimiento de la encriptación de umbral silencioso son bastante favorables. Aquí, n es el tamaño máximo del comité que deseamos admitir, y t es el umbral de descifrado.

La encriptación y la desencriptación parcial son operaciones de tiempo constante. La implementación simple de encriptación tarda menos de 7 milisegundos y se puede paralelizar. La desencriptación parcial tarda menos de 1 milisegundo.

El tamaño del texto cifrado es 768 bytes más grande que el texto sin formato, que es un factor aditivo constante (para cualquier n y t).

La decodificación parcial de la agregación (es decir, la decodificación) depende del tamaño del comité. Cuando n=1024, la implementación simple toma menos de 200 milisegundos. Esperamos que este tiempo se reduzca diez veces cuando n=128 (el tamaño del comité de autenticación en cada ranura) y la implementación se pueda optimizar aún más.

Es importante que el tiempo de encriptación sea un indicador clave de rendimiento en comparación con la latencia del repetidor. Esto es algo que los constructores deben calcular en el 'camino crítico' generado por el bloque. Este tiempo debe ser inferior a la latencia de procesamiento del bloque actual del repetidor y evita la comunicación multi-salto.

Publicación de datos

La encriptación de umbral sin sonido no es completamente gratuita. De hecho, requiere una cadena de referencia común en forma de (g, gτ, gτ², …, gτⁿ⁻ᵗ), similar al contenido utilizado en el esquema de compromiso polinomial KZG.

Además, cada validador de BLS Llave pública, que tiene la forma g⁽sk⁾, publica un conjunto de elementos de grupo que llamamos "cues": (g⁽sk⁾⋅τ, ..., g⁽sk⁾⋅τⁿ⁻t). Estos consejos solo son necesarios cuando se agrega Llave pública y se descifra Texto cifrado. La encriptación solo utiliza el agregado de tamaño constante Llave pública.

Hasta el momento de escribir este artículo, hay aproximadamente 1 millón de validadores. Si configuramos n=128 y t=n/2, cada validador necesita publicar aproximadamente 3KB de pistas. Por lo tanto, almacenar todas las pistas de los validadores requeriría 3GB de espacio.

Con la activación de MaxEB, este requisito podría soltarse significativamente, MaxEB permite a los validadores que controlan más de 32 ETH mantener saldos más grandes bajo una única llave secreta (en lugar de dispersarlos en múltiples depósitos de 32 ETH). La reducción del conjunto de validadores implementados aún está pendiente de discusión. Podríamos reducirlo a aproximadamente 1 GB.

Finalmente, de acuerdo a los futuros cambios en la arquitectura de Ethereum Consenso (por ejemplo, una reducción adicional en el tamaño de la colección de validadores o la sustitución de la línea de tiempo final), el tamaño de las pistas que deben ser almacenadas podría reducirse aún más.

Vitalidad

La red ETH desea permanecer en línea incluso en condiciones desfavorables. Un problema con este enfoque es que, debido a que un comité designado está fuera de línea en ciertas proporciones, puede haber Bloquear que no se puedan descifrar.

Una solución es permitir que los constructores determinen la proporción de comité aceptable (t) para la descifrado. Existe un equilibrio entre la privacidad (posibilidad de desencriptar y robo de MEV) y la posibilidad en línea del umbral del comité. Para los constructores, maximizar sus Bloquear incluidos en la cadena en lugar de fork es maximizar los ingresos, por lo que deben encontrar una configuración de umbral optimizada.[4]

Además, el uso de este esquema de encriptación debe ser voluntario. En caso de condiciones de red desfavorables, si no hay ningún comité de escala aceptable disponible de forma continua en línea, los proponentes y constructores pueden recurrir a utilizar un repetidor, construir uno propio o utilizar otros mecanismos elegidos según la naturaleza desfavorable del entorno.

En concreto, el valor esperado para los constructores de Bloquear que se bifurcan es negativo (no obtienen ingresos), mientras que el valor esperado para desbloquear es muy negativo. Si se les permite a los constructores elegir t en el intervalo [0, 128], deberían ser naturalmente motivados para elegir un t lo suficientemente alto como para soltar el riesgo de desbloqueo y aumentar la probabilidad de ser satisfechos (al menos con t miembros del comité en línea). En condiciones normales de red, algunos Bloquear pueden bifurcarse, pero observamos que esto ya ha sucedido en el juego temporal y la actividad de la cadena sigue siendo aceptable. [↩]

Bloque no disponible

Además, el comité puede estar en línea, pero el constructor puede crear una situación en la que el Bloquear no se pueda descifrar o sea inválido al descifrarlo (por ejemplo, mediante pruebas fraudulentas).

Desde el punto de vista del protocolo, es posible bifurcar estos bloques. Simplemente no es posible para un conjunto más amplio de validadores demostrar este tipo de bloques o cualquier bloque que los cite. La mejor manera de abordar este error puede ser hacer que el cliente de consenso sea consciente de esta posibilidad y pueda fallar con gracia. Se necesita más investigación al respecto.

Estructura del mercado

Los constructores ganadores saben el contenido de Bloquear antes de alcanzar el umbral, lo que puede resultar en una ventaja injusta en el período posterior. Sin embargo, el comité de pruebas debe actuar antes de que finalice el próximo período, y la mayor parte del valor de Bloquear se concentra al final del período, por lo que el impacto de esta ventaja debe minimizarse tanto como sea posible.

Prueba criptográfica pura

A largo plazo, puede haber la posibilidad de reemplazar la prueba de enclave seguro (TEE) con la prueba de conocimiento cero (ZK) . Actualmente, la velocidad de ZK es demasiado lenta, pero los avances en criptografía, software y hardware especializado (ASIC) podrían hacer que la generación de ZK sea factible dentro de los límites de latencia necesarios. Es importante tener en cuenta que la ZK con Bloquear ya es parte central del mapa de ruta a largo plazo de Ethereum.

Adoptar

Según el tamaño y la tasa de crecimiento actual de los validadores, este enfoque puede no valer la cantidad de datos necesarios para desplegarlo en L1. Sin embargo, Ethereum ya ha planeado reducir significativamente la cantidad de validadores a través de MaxEB.

La mejor manera puede ser actualizar antes o después de MaxEB para que el cliente de consenso pueda darse cuenta de la posibilidad de la semántica de encriptación de bloquear y animar a los validadores a publicar sugerencias. Por ejemplo, después de MaxEB, se puede requerir que los validadores recién agregados publiquen sugerencias, mientras que los validadores existentes pueden recibir incentivos para la actualización.

Una vez que un número suficiente de validadores adopte este mecanismo, los constructores comenzarán a usarlo para garantizar un tamaño de comité adecuado (es decir, equilibrar la privacidad y la posibilidad de descifrado).

Si nuestro enfoque es realmente superior en términos de latencia en comparación con el reenvío de múltiples saltos, es probable que el mercado lo adopte de forma espontánea sin necesidad de imponer el uso de protocolos o establecer configuraciones parametrizadas específicas.

Principios básicos

Repetidor es una de las fuentes centralizadas más importantes de Ethereum, lo que lleva a oportunidades de alquiler y distorsiona la geografía del protocolo de Descentralización. Necesitamos eliminar el Repetidor y considerarlo como una solución relativamente elegante. Requiere cambios en la capa de consenso, pero los validadores no necesitan proporcionar nuevo hardware o material de llave secreta.

La desventaja es que este es un cambio complejo en la capa de consenso, y este mecanismo (si se adopta selectivamente como se sugiere) puede o no ser aceptado por el mercado. Sin embargo, muchos posibles cambios en los canales de MEV también enfrentan problemas similares de adopción y optimización de beneficios (por ejemplo, incluyendo listas). Además, en el futuro, puede haber otros casos de uso que dependan de la infraestructura de encriptación de umbral de posesión de un conjunto de validadores.

Descargo de responsabilidad:

1. Este artículo es una reproducción de[paradigm], los derechos de autor pertenecen al autor original [Charlie NoyesGuru, Vamsi Policharla]. Si tiene alguna objeción a la reproducción, comuníquese con el equipo de Gate Learn y el equipo la procesará lo antes posible según los procedimientos correspondientes.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son solo los del autor y no constituyen ninguna recomendación de inversión.
3. Los otros idiomas de los artículos son traducidos por el equipo de Gate Learn, y no se permite copiar, difundir ni plagiar los artículos traducidos sin mencionar a Gate.io.